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ABSTRACT 


Currently,  reasoning  about  key  lengths  within  a  security  scheme  involves  utilizing 
generalized  recommendations  or  conducting  lengthy  manual  analyses  of  how  security  pa¬ 
rameters  relate  to  the  security  of  the  scheme.  In  this  paper,  we  provide  the  tools  necessary 
for  automating  reasoning  about  key  lengths  and  effective  security  within  a  security  scheme. 
We  first  formalize  the  reasoning  about  cryptographic  proofs  within  an  attack  tree  structure, 
then  expand  attack  tree  methodology  to  include  cryptographic  reductions.  We  then  provide 
the  algorithms  for  maintaining  and  automatically  reasoning  about  these  expanded  attack 
trees.  We  provide  a  software  tool  that  utilizes  machine-readable  proof  and  attack  metadata 
and  the  attack  tree  methodology  to  provide  rapid  and  precise  answers  regarding  security 
parameters  and  effective  security.  This  eliminates  the  need  to  rely  on  generalized  recom¬ 
mendations  and  provides  timely  reanalysis  when  newfound  attacks  or  proofs  surface.  We 
validate  our  software  tool  within  the  Schnorr  public-key  signature  scheme  as  a  case  study. 
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CHAPTER  1: 

Introduction 


Currently,  when  an  organization  reasons  about  keylength,  it  is  left  to  choose  from  an 
array  of  sometimes  conflicting  recommendations  provided  by  several  organizations.  These 
recommendations  are  typically  generalized  and  furnish  conservative  values.  Furthermore, 
the  organizations  that  maintain  them  tend  to  update  them  with  a  periodicity  of  a  year  or 
more  regardless  of  newly  published  papers  or  newly  found  attacks  that  may  affect  them. 

The  alternative  to  this  method  involves  a  cryptographer  reasoning  about  keylength  through 
an  analysis  relating  security  parameters  of  a  particular  scheme  to  its  effective  security.  This 
is  done  with  security  proofs  (typically  manual)  that  relate  the  parameters  and  effective 
security.  This  method  is  less  general  than  the  recommendations  and  can  be  updated  as  often 
as  one  can  afford;  however,  it  can  be  arduous  and  requires  experts  to  complete. 

We  explore  developing  a  software  tool  that  can  automate  the  reasoning  about  keylength 
for  a  cryptographic  scheme.  This  software  tool  applies  machine-readable  proof  and  attack 
metadata  using  an  attack  tree  approach  to  provide  timely  and  accurate  answers  concerning 
security  parameters  and  effective  security.  Being  derived  from  an  attack  tree  methodology, 
this  approach  naturally  inherits  extensibility  and  modularity.  This  research  expands  tradi¬ 
tional  attack  tree  analysis  to  consider  symbolic  constraints  related  to  proof  tightness  and 
attack  cost.  This  allows  experts  in  one  domain  (e.g.,  attacks  employing  the  general  number 
field  sieve)  to  inform  experts  from  another  domain  (e.g.,  the  relationship  between  the  sub¬ 
group  discrete  log  problem  and  some,  specific  hybrid  signature  scheme)  by  supplying  new 
modules  with  appropriate  metadata.  This  makes  this  type  of  reasoning  significantly  more 
dynamic.  Its  modular  design  allows  organizations  to  incorporate  new  attack  metadata  and 
make  prompt,  informed  reactions  to  new  attacks  or  security  announcements.  Furthermore, 
precisely  and  immediately  re-generating  analyses  related  to  security  parameters  enables 
counter-factual  reasoning  about  these  proofs:  would  improving  the  tightness  bounds  of 
prior  work  effectively  strengthen  the  security  of  a  scheme  (or  does  some  other  factor  cre¬ 
ate  a  bottleneck)?  Given  some  selection  parameters,  what  is  the  effective  security  of  the 
resulting  scheme?  What  parameters  should  one  select  to  yield  a  desired,  target  effective 
security? 
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Our  research  contributes  the  following  to  the  area  of  reasoning  about  the  effective  security 
of  a  security  scheme: 


•  We  formalize  a  method  for  reasoning  about  cryptographic  proofs  using  attack  trees; 

•  We  expand  attack  tree  analysis  to  include  cryptographic  reductions  and  provide  al¬ 
gorithms  for  maintaining  and  automatically  reasoning  about  these  enhanced,  crypto¬ 
graphic  attack  trees; 

•  We  provide  a  proof-of-concept  software  tool,  implemented  in  Python  and  leveraging 
the  SymPy  symbolic  solver  library;  and 

•  We  validate  our  tool  using  the  Schnorr  public -key  signature  scheme  as  a  case  study, 
comparing  the  results  of  our  automated  analysis  with  relevant,  existing  keylength 
recommendations . 


1.1  Organization 

In  Chapter  2,  we  discuss  existing  methods  for  determining  an  appropriate  keylength  for  a 
security  scheme  and  review  existing  work  on  automated  cryptographic  proving.  In  Chap¬ 
ter  3,  we  formalize  reasoning  within  attack  tree  structures,  expand  attack  tree 
methodology  to  include  cryptographic  reductions  and  introduce  our  case  study,  the 
Schnorr  signature  scheme.  In  Chapter  4,  we  cover  the  concept  of  operations  of  our 
software  tool  and  some  characteristics  we  set  to  achieve  with  our  design.  In  Chapter  5, 
we  discuss  our  software  tool  implementation  and  discuss  the  algorithms  driving  the 
analysis  engine  of  our  software  tool.  We  then  examine  some  of  the  results  of  the 
software  tool  and  compare  these  results  with  existing  methods.  In  Chapter  6,  we  conclude 
and  discuss  future  work. 
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CHAPTER  2: 
Background 


In  this  chapter,  we  review  current  keylength  analysis  techniques,  the  properties  of  crypto¬ 
graphic  proofs  required  to  perform  a  detailed  keylength  analysis  and  related  research  on 
automated  proving  for  cryptographic  constructions. 


2.1  Keylength  Analysis 

Reasoning  about  cryptographic  parameters  requires  an  mathematical  analysis  relating  the 
schemes’  security  parameters  to  the  effective  security  of  the  resulting  scheme.  When  a 
scheme  is  argued  to  have  effective  security  of  n  bits  given  some  choice  of  parameters,  this 
characterizes  the  cost  of  attacking  the  scheme  as  equivalent  in  cost  to  brute-forcing  some 
notional,  symmetric  system  with  an  n-bit  secret  key,  i.e.,  an  effort  of  approximately  2” 
operations  [1].  For  many  schemes,  there  is  a  discrepancy  between  the  security  parameter 
and  effective  security  for  that  scheme,  based  on  the  details  of  the  construction  and  its 
proof  of  security.  For  example,  3DES  uses  three  keys  each  of  length  56  bits  yet  it  is  well- 
understood  this  construction  does  not  yield  a  block  cipher  with  168-bits  of  effective  security 
(3  X  56  bits);  instead,  3DES  has  been  shown  to  have  an  effective  security  of  1 12-bits.  More 
efficient  attacks  against  any  system  may  exist,  utilizing  vulnerabilities  in  its  implementation, 
in  the  properties  of  its  underlying  building-blocks,  in  its  environment  or  via  its  users  [1]. 
The  scope  of  our  analysis  is  to  those  properties  and  attacks  covered  by  the  security  proof 
associated  with  the  scheme. 

Cryptography  requires  a  security  proof  relating  parameters  to  effective  security.  Both  proof 
construction  and  proof  analysis  entails  domain-expert  knowledge  and  can  be  a  laborious 
and  nuanced  process.  New  questions  may  not  be  able  to  re-use  the  results  of  prior  analysis 
(i.e.,  when  the  prior  assumptions  were  not  general  or  when  the  context  is  slightly  different). 
Instead,  new  questions  may  require  whole-cloth  re-analysis. 

When  organizations  determine  policy  or  select  cryptographic  parameters,  they  may  find  it 
too  costly  to  conduct  an  in-depth  proof  analysis.  Instead,  they  rely  on  guidance  published  by 
academic,  government  and  private  organizations  such  as  the  National  Institute  of  Standards 
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and  Technology  (NIST),  the  Bundesamt  fur  Sicherheit  in  der  Informationstechnik  (BSI), 
the  National  Security  Agency  and  the  Internet  Engineering  Task  Force.  For  example,  NIST 
presents  “best  practice”  parameters  codified  in  look-up  tables  in  publications  which  undergo 
periodic  update,  every  two  to  four  years  [2].  During  this  period,  the  cost  of  some  attacks 
may  reduce,  e.g.,  because  of  the  increase  in  computer  performance,  decrease  in  resource 
cost  or  the  discovery  of  new  attack  methods  [1].  While  the  effects  of  Moore’s  law  can  be 
projected,  the  effect  of  new  attacks  on  a  system’s  effective  security  may  not  be  apparent 
without  a  whole-cloth  re-analysis.  These  impacts  may  not  be  disseminated  until  guidance  is 
updated,  if  it  is  updated.  In  general,  these  published  “best  practice”  parameters  are  intended 
to  be  relatively  conservative;  however,  as  periodic  review  is  a  human  process,  opportunities 
to  re-think  guidance  is  perhaps  not  as  timely  as  circumstances  may  warrant.  Beyond  the 
possibility  of  being  outdated,  the  limited  context  of  the  analysis  codified  in  this  guidance 
makes  it  inappropriate  to  leverage  to  answer  new  questions  regarding  security. 

Referring  to  one  of  these  “best  practice”  key  length  publications  is  certainly  more  accessible 
than  a  complete  re-analysis,  but  it  can  be  cumbersome  as  well.  Furthermore,  these  guide¬ 
lines  are  not  always  in  agreement,  creating  a  new  hardship  involving  deciding  upon  which 
cryptographic  guidance  is  most  appropriate.  Giry  aggregates  the  keylength  guidance  from 
organizations,  providing  this  as  a  resource  through  an  interactive  website  [3].  It  allows  one 
to  quickly  compare  the  results  of  each  report  against  one  another  to  aide  organizations  in 
making  a  decision  about  security  parameters  [3].  While  this  reduces  the  workload  associ¬ 
ated  with  reading  and  interpreting  this  guidance,  by  putting  each  in  relatively  comparable 
terminology,  the  timeliness  of  information  and  resolving  discrepancies  remain  as  problems. 


2.2  Methods  for  Achieving  Provable  Security 

To  date,  it  has  been  common  to  describe  reductionist  security  proofs  in  one  of  two  ways, 
as  asymptotic  guarantees  or  as  concrete  guarantees.  The  asymptotic  setting  was  arguably 
first  employed  by  Rabin  in  1979  [4]  and  has  been  in  relatively  common  use  since.  In  a 
reductionist  security  argument,  a  proof  of  security  involves  a  reduction  between  breaking 
the  security  of  the  system  to  solving  a  computationally  hard  problem  [5].  In  the  asymptotic 
setting,  this  reduction  yields  statements  such  as  “for  a  sufficiently  large  security  parameter 
A,  no  polynomial-time  adversary  has  more  than  non-negligible  probability  of  success  in 
breaking  the  security  property  for  the  scheme”  [5].  In  the  concrete  setting,  introduced 
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by  Bellare  and  Rogaway,  the  goal  is  to  produce  more  practice-oriented  statements  [6]. 
A  concrete  proof  of  security  yields  statements  such  as  “an  attacker,  within  time  t  and 
employing  q  queries  to  a  problem-solving  oracle  O,  is  able  to  break  the  security  property 
for  the  scheme  under  security  parameter  A  with  at  most  e  probability  of  success”  [7]. 

Each  type  of  proof  has  advantages  and  disadvantages.  For  example,  it  appears  some  schemes 
are  simpler  to  prove  secure  in  the  asymptotic  setting.  It  is  not  the  goal  of  our  research, 
however,  to  criticize  these  two  paradigms  or  to  determine  if  one  setting  is  more  useful 
than  the  other,  generally.  The  purpose  of  our  software  tool  is  to  provide  accurate  answers 
regarding  security  parameters  and  effective  security;  thus,  we  have  chosen  to  reason  in  the 
concrete  security  setting.  This  allows  us  to  precisely  characterize  the  cost  of  security  due 
to  the  tightness  of  proof  reductions  and  it  allows  us  to  interpret  more  accurate  values  for 
attack  cost  for  given  security  parameters  [8]. 


2.3  Automated  Proof  Generation 

The  academic  community  is  continuously  striving  to  create  new  cryptographic  proof  tech¬ 
niques,  firmly  grounded  in  mathematical  foundations,  to  provide  more  easily  verifiable 
guarantees  with  stronger  results  when  analyzing  cryptographic  constructions  [9].  Building 
on  the  work  of  Dolev  and  Yao  [10],  Kilian  and  Rogaway  [11],  Bellare  and  Rogaway  [12] 
and  others,  the  community  has  sought  new  methods  to  verify  the  correctness  of  machine- 
readable  cryptographic  proofs  and  to  generate  cryptographic  proofs,  in  either  a  fully  auto¬ 
matic  or  machine-assisted  manner. 

For  some  examples,  Cortier  and  Warinschi  [9]  employ  an  existing  tool  called  Casrul  for 
automatically  generating  sound  proofs  in  the  computational  model.  Barthe  et  al.  intro¬ 
duce  EasyCrypt,  a  tool  for  machine-assisted  security  proofs  from  proof  sketches  using  the 
CertiCrypt  framework  and  available  proof  verifiers  [13].  Blanchet  introduces  ProVerif, 
a  cryptographic  protocol  verifier  in  the  formal  model  [14].  Blanchet  later  extends  this 
tool  as  CryptoVerif,  an  automatic  protocol  prover  sound  in  the  computational  model  [15] 
demonstrated  to  prove  secrecy  for  a  number  of  key  exchange  protocols. 

Our  software  tool  does  not  provide  automatic  proof  generation,  rather  providing  automatic 
analysis  derived  from  proofs.  The  goal  of  our  software  tool  is  to  employ  concrete  security 
proofs  to  determine  guidance  about  security  parameters  or  deriving  effective  security.  Our 
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software  tool  uses  metadata  about  eonerete  proofs  to  reason  about  seeurity  parameters  and 
effeetive  seeurity.  In  the  future,  it  may  be  possible  to  bridge  automatie  proof  generation 
and  our  software  tool.  It  may  be  possible  to  analyze  the  proofs  from  automated  tools,  or 
interpret  it  direetly  using  a  modified  version  of  our  software  tool.  This  would  allow  the 
ehain  of  automation  to  be  extended  from  proof  generation  to  ineluding  reasoning  about 
effeetive  seeurity  and  reeommending  parameters. 
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CHAPTER  3: 

Cryptographic  Attack  Tree  Analysis  Model 


The  target  outcome  of  this  research  is  a  proof-of-concept  software  tool  able  to  reason  about 
effective  security,  automatically  and  dynamically,  given  different  parameter  options.  It  uses 
machine -readable  proof  and  attack  metadata  to  provide  accurate  answers  regarding  security 
parameters  and  effective  security  within  a  security  scheme.  Here,  we  propose  a  method 
to  analyze  this  metadata  based  on  attack  trees.  Since  our  methodology  is  based  on  attack 
trees,  our  software  tool  inherits  many  benefits  traditionally  associated  with  attack  trees,  e.g., 
extensibility  and  modularity. 

We  discuss  the  model  and  concepts  traditionally  associated  with  attack  trees  in  Section  3.1. 
Our  methodology  expands  typical  attack  tree  analysis,  however,  to  consider  symbolic  con¬ 
straints  related  to  proof  tightness  and  attack  costs.  Inclusion  of  those  constraints  related 
to  proof  metadata,  however,  requires  attack  cost  calculations  associated  with  traditional 
attack  trees  to  become  more  complicated,  especially  when  multiple  reductions  may  exist 
between  attack  objectives,  which  we  discuss  in  Section  3.2.  We  present  a  case  study  for  this 
methodology  in  Section  3.3,  employing  Schnorr’s  digital  signature  scheme. 


3.1  Attack  Trees 

To  better  understand  the  weaknesses  within  a  system,  one  can  examine  the  system  based  on 
known  methods  of  attacking  it.  An  attack  tree  is  a  method  of  representing  attacks  against 
the  system  in  a  tree  structure,  allowing  analysis  of  attack  dependencies  and  costs.  This 
method  has  been  popularly  discussed  by  Schneier  and  is  considered  mature  [16].  Several 
projects  exist  allowing  security  researchers  to  employ  attack  trees  for  formalized  red-team 
brainstorming  and  prioritizing  system  weaknesses,  including  ADTool  [17],  AttackTree  [18], 
and  SeaMonster  [19]. 

In  a  typical  attack  tree,  a  goal  G  is  related  to  a  set  of  subgoals,  5i, . . . ,  sj,  each  represented 
as  nodes  in  a  directed  graph  (see  Figure  3.1).  To  achieve  goal  G,  an  attacker  must  satisfy 
its  subgoal  dependencies.  When  two  subgoals  must  both  be  satisfied  to  achieve  the  goal, 
its  edges  are  labeled  with  a  boolean  “and”  expression  to  express  this  dependency.  Unless 
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otherwise  noted,  edges  represent  subgoals  in  an  “or”  relationship,  where  satisfying  any 
subgoal  achieves  the  goal.  We  denote  an  edge  connecting  goals  G  and  dependency  subgoal 
Si  as  G  ^  Si. 


Figure  3.1:  A  simple  attack  tree,  showing  the  relationship  between  goals  and 
subgoals. 


Figure  3.1  is  a  representation  of  a  small  attack  tree.  In  a  larger  tree,  each  subgoal  Si  may 
have  subgoals  itself,  modeled  as  the  children  of  node  Si,  and  so  on.  When  the  attack  tree  is 
complete,  the  objective  G  can  be  achieved  by  finding  a  set  of  paths  from  the  leaves  to  the 
root,  while  satisfying  the  boolean  restrictions  attached  to  the  edges  involved  in  that  path. 
In  the  remainder  of  our  work,  we  do  not  utilize  any  “and”  edges  in  our  attack  trees  and  all 
subgoals  are  in  an  “or”  relationship.  Thus,  for  this  case,  accomplishing  G  is  equivalent  to 
following  a  path  from  any  leaf  to  G. 

Consider  the  following  example  proposed  by  Schneier  [16].  A  thief  wishes  to  access  a 
3-hour  safe  (G).  The  thief  can  pick  the  lock  (51),  use  a  blow  torch  to  cut  into  the  safe  (52)  or 
guess  the  combination  (53).  Achieving  any  of  these  subgoals  is  sufficient  to  achieve  the  goal 
G,  but  each  have  different  costs,  in  terms  of  money,  time,  skill,  etc.  Attaining  each  subgoal 
may,  itself,  incur  some  prerequisites  (e.g.,  buying  the  blowtorch),  which  can  be  modeled  as 
further  subgoals. 

In  order  to  characterize  the  relative  security  of  the  system,  one  can  annotate  the  nodes  of 
the  tree  to  support  attack  cost- analysis.  These  annotations  may  represent  the  time  or  money 
required  to  achieve  a  subgoal.  The  values  assigned  to  nodes  are  not  limited  in  any  fashion: 
one  can  assign  a  value  indicating  probability  of  attack  success,  level  of  attack  complexity, 
pre-requisite  skills  or  required  equipment  [16].  These  values  allow  for  flexible  reasoning 
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about  the  security  of  the  system.  With  these  annotations,  one  can  use  the  attack  tree  to 
reason  about  which  attack  may  be  launched  with  the  highest  probability  of  success  and  the 
lowest  complexity,  or  the  analysis  of  which  attack  is  the  cheapest  [16].  We  refer  the  reader 
to  Schneier  for  further  explanation  of  the  utility  of  attack  tree  methodology  for  modeling 
computer  systems  [16]. 

When  calculating  the  cost  to  execute  a  successful  attack  against  the  system  in  question, 
one  must  make  some  assumptions  about  the  adversary  potentially  performing  the  attack. 
In  this  work,  we  assume  the  adversary  is  capable  of  utilizing  any  attack  path  and  will 
choose  the  path  with  the  minimum  cost.  Thus,  no  subgoal  is  impossible  to  achieve  and  we 
consider  all  node  annotations  to  characterize  cost,  in  some  sense.  We  denote  the  cost  to 
reach  node  x  as  Cost(x).  Given  edge  x  ^  ?/,  the  cost  to  achieve  goal  x  using  subgoal  y 
is  Cost(x  ^  y).  In  many  cases,  Cost(jc  y)  =  Cost(y).  Consider,  however,  our  prior 
example:  if  cost  is  dollars,  y  is  “renting  a  blowtorch  for  an  hour,”  x  is  “attacking  a  3-hour 
safe”  and  Cost(i/)  =  $100,  then  it  may  be  the  case  that  Cost(x  y)  =  $300.  To  calculate 
the  minimum  cost  to  the  attacker  for  achieving  G,  we  consider  the  minimum  cost  attack 
terminating  at  G: 

Cost(G)  =  min{Cost(G  ^  sj)}.  (3.1) 

j 

For  example,  in  Figure  3.2  we  show  that  the  lowest  cost  associated  with  any  of  the  attack 
paths  from  the  subgoals  of  G  is  Cost(G  ^  vi).  As  a  result,  we  have  propagated  that  value, 
in  this  case  20,  to  Cost(G).  We  can  apply  this  procedure  for  calculating  costs  from  the 
leaves  of  a  completed  tree  all  the  way  to  the  root  to  arrive  at  the  overall  cost  to  break  the 
system. 
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Figure  3.2:  An  attack  tree  with  cost  annotations. 


3.2  Attack  Trees  with  Reductions 

We  expand  traditional  attack  trees,  allowing  a  node  to  be  annotated  with  an  arbitrary  set  of 
parameters  and  an  edge  to  be  associated  with  a  set  of  reductions  (see  Figure  3.3). 


Figure  3.3:  Reductions  as  relations  between  variables  associated  with  sub¬ 
goals. 


Let  node  s  be  associated  with  the  set  of  free  variables  Var^,  which  can  be  partitioned 
into  two  types:  security  parameters  (Param^)  and  cost  parameters  (Cost^).  For  example, 
p  6  Param^  c  Var^  may  be  a  variable  characterizing  key  length  and  r  6  Cost^  c  Var^ 
may  be  a  variable  related  to  time  complexity.  Every  variable  cr  6  Var^  has  an  associated 
domain  Dom(cr)  over  which  this  free  variable  ranges  and,  given  any  finite  set  of  values  in 
this  domain,  the  minimum  and  maximum  are  well-defined.  Edge  g  ^  s  may  be  annotated 
with  a  reduction  r.  A  reduction  r  is  a  group  of  relations  among  Var^  and  Var^: 

r  =  fc7s7  rp7rim,  47ram}  whcrc  r^^^t  is  a  relation  /  :  Var,  ^  Cost^ 
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For  example,  is  a  relation  expressing  cost,  in  terms  of  variables  from  Cost^,  to  achieve 
g  by  employing  subroutine  s  and  instantiating  its  variables  Var^. 

Reduction  r  can  be  interpreted  as  a  guarantee  that  an  adversary,  given  a  subroutine  solving 
5,  will  incur  a  cost  greater  than  or  equal  to  some  guaranteed  minimum  cost  (GMC)  to  solve 
g.  We  define  the  GMC  indicated  by  reduction  r  when  subroutine  s  is  instantiated  with 
variables  p  as: 

GMCr\p)  =  rtTJ(P)  (3-2) 

Returning  to  our  prior  example,  consider  an  experiment  to  determine  the  minimum  time  to 
access  a  particular  safe  with  a  blow  torch.  The  analysts  are  given  some  characteristics  p 
for  the  blow  torch  (e.g.,  it  uses  acetylene  gas,  burns  at  6000°F).  The  experiment  predicts  a 
conservative  lower-bound  for  attack  time  to  be  at  least  two  hours.  The  experiment  is  a  type 
of  reduction,  specific  to  that  goal  (g),  employing  a  general  attack  using  a  blowtorch  (s)  in 
the  context  of  that  torch’s  parameters  (p)  yielding  two  hours  as  the  GMC. 

As  a  result  of  ongoing  efforts  to  improve  or  tighten  security  reductions,  there  may  be  several 
reductions  relating  subgoals  (see  Figure  3.4).  Returning  to  our  example,  this  is  analogous  to 
new  experiments  yielding  improved  bounds  on  the  time  to  open  the  safe  with  the  blowtorch, 
finding  it  takes  at  least  three  hours  based  on  a  more  careful  analysis,  rather  than  at  least  two 
hours.  We  note  that  had  experiments  revealed  that  the  safe  could  be  opened  in  one  hour 
using  the  blowtorch,  this  would  not  be  a  tighter  reduction  but,  in  fact,  a  refutation  of  the 
prior  reduction,  demonstrating  it  to  have  been  unsound.  In  our  model,  we  assume  all  our 
reductions  are  mathematically  correct  and  sound. 


Figure  3.4:  Each  reduction  yields  a  different  relation,  and  may  yield  a  differ¬ 
ent  GMC. 
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3.2.1  Propagating  Values  “Up”  the  Tree 

Let  R{g,  s)  =  {ri, . .  .,r,}  be  the  set  of  all  reduetions  relating  ^  to  g.  Each  reduction  r, 
may  yield  a  different  GMC  under  conditions  p  6  Var^,  yielding  different  relations  for  cost 
(see  Figure  3.4).  Given  multiple  reductions  yielding  different  GMCs,  we  must  determine 
which  GMC  to  utilize  in  determining  the  cost  along  that  particular  attack  path.  Assuming  all 
reductions  are  sound,  the  greatest  lower  bound  (infimum)  yields  the  overall  GMC  expressing 
cost  for  edge  g  ^  5.  The  cost  to  achieve  goal  ^  via  the  attack  path  using  subgoal  ^  is  therefore 
the  maximum  over  all  GMCs  for  reductions  relating  s  to  the  cost  of  solving  g: 

GMC(^  ^  s)=  max  (GMC^^")  (3.3) 

i 

In  order  to  calculate  the  cost  of  achieving  G  when  dealing  with  multiple  attack  paths  to  G, 
one  must  first  determine  the  GMCs  of  each  reduction  relating  each  subgoal  to  the  goal  (from 
Equation  3.2).  Then,  the  cost  along  each  attack  path  is  resolved  by  taking  the  maximum 
along  that  path  (from  Equation  3.3).  Finally,  we  determine  the  cost  to  achieve  G  (from 
Equation  3.1). 

For  example,  consider  the  example  tree  from  Figure  3.5  and  its  related  information  from 
Figure  3.6. 


Figure  3.5:  A  simple  attack  tree,  showing  multiple  reductions. 
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•  S.t  6  Costi  c  Var^,  a  variable  related  to  time  complexity 

•  u.t  6  Cost„  c  Varj(,  a  variable  related  to  time  complexity 

•  g.t  &  Cost^  c  Var^,  a  variable  related  to  time  complexity 

•  ri  has  relation  s.t  <  2^^  x  g.t’ 

•  r2  has  relation  s.t  <2^^  x  g.t^ 

•  Vu  has  relation  u.t  =  2x  g.t 

Figure  3.6:  Symbols  and  relations  for  the  tree  in  Figure  3.5. 

If  we  find  that  s.t  =  2^*^,  r\  yields  g.t  >  2^®  and  ra  yields  g.t  >  2^*^.  So,  reduction  r\  states 
that  goal  g  is  secure  against  an  adversary  running  in  time  <  2^®  while  reduction  r2  states  that 
goal  g  is  secure  against  an  adversary  running  in  time  <  2^®.  We  choose  the  value  yielded 
by  reduction  r2  (applying  Equation  3.2)  because  it  makes  the  stronger  security  claim.  We 
then  can  say  that  the  cost  to  achieve  goal  g  via  the  attack  path  using  subgoal  5  is  2^®.  If 
we  find  u.t  =  2^®,  yields  g.t  =  2^^.  So,  we  apply  Equation  3.1  to  determine  the  cost  to 
achieve  goal  g  =  2^^. 


3.2.2  Propagating  Values  “Down”  the  Tree 

Thus  far,  we  have  discussed  and  given  examples  of  propagating  values  “up”  the  attack  tree, 
from  subgoals  to  goals.  We  now  discuss  propagating  values  “down”  the  attack  tree  from 
goals  to  subgoals.  There  are  differences  that  surface  when  propagating  values  “down”  the 
tree.  These  differences  are  mainly  in  how  security  parameters  and  costs  are  reduced  between 
two  nodes  and  how  we  choose  which  values  will  get  propagated  into  a  node  from  its  edges. 

When  traversing  down  the  tree,  instead  of  employing  the  guaranteed  minimum  cost,  we 
employ  the  guaranteed  peak  cost  (GPC).  The  GPC  characterizes  the  smallest  security 
parameters  guaranteeing  some  lower-bound  cost  on  attacker  effort.  Given  t  6  Cost^,  we 
define  GPC  as: 

GPCr'CO  =  47rL(t)  =  P  6  Param,  (3.4) 

When  dealing  with  multiple  reductions,  each  will  produce  a  lower-bound  on  the  time  for 
attacker  effort.  Assuming  all  reductions  are  sound,  the  least  upper  bound  (supremum)  yields 
the  smallest  guaranteed  attack  cost  for  g  given  the  ability  to  solve  5.  The  cost  to  parameters 
to  employ  g  via  the  attack  path  using  subgoal  s  is  therefore  the  minimum  over  all  GPCs  for 
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reductions  relating  g  to  the  cost  of  solving  s: 


GPC(g  s)=  min  (GPCff ") 

i  ’’ 


(3.5) 


Again,  consider  the  example  tree  in  Figure  3.5  and  related  information  from  Figure  3.6.  If 
we  are  given  g.t  =  2^0  ,  r\  yields  s.t  <  2^^^  and  r2  yields  s.t  <  2^^®.  So,  reduction  r\  states 
that,  given  an  adversary  breaking  g  in  time  2^®  then  there  exists  an  adversary  breaking  s  in 
time  <  2^^^,  while  reduction  r2  states  that,  under  the  same  condition,  there  is  an  adversary 
breaking  s  in  time  <  2^^®.  We  choose  the  value  yielded  by  reduction  r2  because  is  portrays 
the  tighter  bound  and  represents  the  stronger  adversarial  ability.  We  can  then  resolve  these 
two  reductions  and  claim  the  cost  to  achieve  subgoal  s  =  2^^®,  when  given  an  adversary 
against  g  running  in  time  2^®.  The  reduction  Vu  yields  u.t  =  2^^  Since  there  is  only  one 
reduction  between  goal  g  and  subgoal  u,  we  can  say  the  cost  to  achieve  subgoal  u  =  2^^. 
Thus,  to  achieve  an  effective  security  of  2^®  for  g,  we  must  select  parameters  forcing  s  to 
have  effective  security  of  at  least  2^^®  and  forcing  u  to  have  effective  security  2^^ 


3.3  Case  Study:  The  Schnorr  Signature  Scheme 

To  express  these  ideas  in  the  context  of  a  non-trivial  case  study,  we  consider  the  Schnorr 
public-key  signature  scheme,  with  known  relevant  attacks  and  reductions.  We  selected  this 
target  scheme  because  it  has  the  ability  to  demonstrate  a  variety  of  the  features  previously 
discussed  for  our  methodology.  In  particular,  the  Schnorr  signature  scheme  presents  us  the 
opportunity  to  reason  about  multiple  reductions,  given  the  original  reduction  presented  by 
Schnorr  [20]  and  the  tighter  reduction  by  Pointcheval  and  Stern  [7].  It  also  allows  us  to 
demonstrate  the  situation  where  multiple  attack  subgoals  must  be  analyzed,  and  subgoals 
are  re-used  within  the  tree  in  different  contexts. 

Employing  the  notation  introduced  thus  far,  we  can  express  pictorially  the  attack  tree  for 
our  Schnorr  case  study,  annotated  with  variables  and  reductions  (see  Figure  3.7).  The  root, 
Schnorr  Signature,  represents  a  generic,  high-level  goal  to  break  some  aspect  of  the  signature 
scheme.  There  are  several  notions  of  security  applicable  to  the  signature  schemes — 
e.g.,  security  against  no-message  attacks,  security  against  chosen-message  attacks — each 
yielding  different  trees.  We  have  chosen  to  analyze  one  notion  of  security,  existential  forgery 
under  an  adaptively  chosen- message  attack  (EF-ACMA). 
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Schnorr  Signature 


z 


Figure  3.7:  The  Schnorr  signature  scheme  attack  tree.  Nodes  (black  boxes) 
represent  subgoals  and  edges  (green  lines)  are  annotated  with  reductions 
(green  dots). 


The  subgoal  of  Break  EF-ACMA  is  Break  Subgroup  Discrete  Log  Problem.  The  relationship 
between  these  goals  are  provided  by  two  proofs:  S89,  the  reduetion  originally  provided 
Sehnorr  [20];  and  PSOO,  the  reduetion  provided  by  Pointeheval  and  Stern  [7].  This  is  an 
example  of  the  seenario  diseussed  in  Seetion  3.2.  In  this  ease,  PSOO  provides  the  tighter 
bounds,  improving  a  query  bound  from  0{q^)  to  0{q). 

The  Break  Subgroup  Discrete  Log  Problem  has  two  subgoals:  an  attaek  via  Pollard’s  Rho 
and  reduetion  to  a  related  problem.  Break  Discrete  Log  Problem.  The  Break  Discrete  Log 
Problem  goal  has  subgoals,  most  of  whieh  are  attaeks  or  generalizations  of  attaeks.  One 
attaek  is,  again,  Pollard’s  Rho,  demonstrating  how  a  goal  and  its  subgoals  may  share  a 
eommon  leaf. 

The  leaves  in  the  tree  eaeh  represent  an  attaek,  employing  a  speeifie  algorithm  to  attaek 
the  properties  of  a  goal.  These  are  annotated  with  both  variables  and  relations.  Very 
general  attaeks  like  Exhaustive  Search  ean  be  applied  direetly  to  most  subgoals,  but  we 
omit  those  edges  for  brevity  and  elarity.  The  interested  reader  is  referred  to  the  following 
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resources  for  details  on  the  attack  nodes  in  this  case  study:  Pollard’s  Rho  algorithm  [21], 
Shank’s  Baby-step  Giant- step  algorithm  [22]  and  the  general  number  field  sieve  (GNFS) 
algorithm  [23]. 
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CHAPTER  4: 

Concept  of  Operations  and  Design 


In  this  chapter  we  discuss  concept  of  operations  of  our  software  tool  to  include  propagating 
values  in  both  directions,  described  briefly  in  Section  3.2.  We  discuss  target  features  for 
our  software  tool  and  a  high-level  design  supporting  extensibility  and  modularity. 


4.1  Concept  of  Operations 

In  its  simplest  use,  our  software  tool  should  be  capable  of  resolving  two  types  of  questions: 

1.  Given  some  set  of  security  parameters  (e.g.,  n,  p  and  q),  what  effective  security  is 
provided? 

2.  For  a  desired  target  effective  security,  what  security  parameters  should  be  used? 

In  the  former  case,  the  user  provides  n,  p,  and  q  and  the  tool  returns  the  effective  security 
A.  In  the  latter  case,  the  user  provides  a  target  effective  security  A  and  the  program  returns 
a  set  of  satisfying  parameters  n,  p  and  q. 

Being  able  to  re-run  the  above  analyses  enables  interesting  counter-factual  analyses  for 
prioritizing  new  research.  This  would  enable  us  to  pose  questions,  like,  would  improving 
the  tightness  bounds  of  this  proof  effectively  strengthen  the  security  of  the  scheme,  or  does 
some  other  factor  create  a  bottleneck? 

To  illustrate  the  possible  operation  of  the  analysis  engine  consider  our  case  study  as  an 
example  (see  Section  3.3).  The  user  may  desire  to  calculate  the  security  parameters  required 
to  achieve  a  target  level  of  effective  security  for  the  EF-ACMA  property  for  the  Schnorr 
signature  scheme.  The  level  of  effective  security  can  be  expressed  in  terms  of  a  lower- 
bound  time  required  to  break  this  property.  Thus,  the  user  provides  some  target  value,  like 
^EF-ACMA  =  2^®,  as  the  time  budget  within  which  no  adversary  can  break  EF-ACMA.  In 
response,  the  user  expects  the  tool  to  provide  recommended  values  of  security  parameters, 
such  as  p  (the  size  of  the  prime-order  group)  and  q  (the  size  of  the  subgroup)  for  the  scheme. 
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To  accomplish  this  task,  the  analysis  engine  propagates  the  eost  values  down  the  tree  as 
diseussed  in  Seetion  3.2.2.  The  desired  eost  of  tsF-ACMA  =  2^®  is  passed  through  the  two 
relations  in  the  reduetions  leading  to  the  subgoal  Break  Subgroup  Discrete  Log  Problem 
(see  Figure  3.7)  to  determine  their  GPCs  as  in  the  example  provided  in  Seetion  3.2.2.  The 
eost  of  Break  Subgroup  Discrete  Log  Problem  is  then  determined  utilizing  the  equations 
given  in  Chapter  3.  In  this  case  we  derive  tsDL  =  2^^^  This  proeedure  is  then  repeated 
to  determine  the  eosts  for  the  subgoals  of  Break  Subgroup  Discrete  Log  Problem.  For 
simplicity  we  opt  not  to  step  through  eaeh  ealeulation  down  the  tree.  This  proeess  eontinues 
until  we  have  propagated  all  cost  values  to  each  node  from  EF-ACMA  to  each  of  the  leaves 
shown  in  Figure  3.7.  We  reeall  from  Seetion  3.3  that  eaeh  of  these  nodes  is  a  generalized 
attaek. 

It  is  in  these  leaf  nodes  (attacks)  where  the  eost  value  is  direetly  translated  into  a  seeurity 
parameter  that  requires  an  attaeker  to  undergo  a  particular  cost.  In  other  words,  the  leaf  node 
reduees  to  no  other  problem.  In  our  example,  we  have  now  populated  the  value  tpR  =  2^^^ 
into  the  Pollard’s  Rho  attaek.  We  can  now  utilize  the  approximation  tpR  =  -^npR  to  eonelude 
npR  =  2^^^.  This  ean  be  done  for  all  leaf  nodes. 

Now  that  we  have  values  for  eaeh  seeurity  parameter  in  eaeh  leaf  node,  we  can  propagate 
those  values  up  the  tree  as  deseribed  in  Section  3.2.1.  Again,  we  opt  not  to  step  through 
every  ealeulation.  The  user  now  has  aeeess  to  the  value  of  every  possible  security  parameter 
for  every  node  in  the  attaek  tree  that  would  make  it  impossible  for  an  adversary  to  break  the 
EF-ACMA  property  within  the  2^^  budget  given.  For  instanee,  the  user  can  now  see  that 
p  =  2354. 

This  example  exhibits  the  need  to  make  two  passes  through  the  tree  (up  and  down)  in  order 
to  provide  values  for  parameters  when  given  a  target  effeetive  seeurity.  The  process  is 
also  neeessary  when  the  analysis  engine  provides  the  effeetive  seeurity  when  given  a  set  of 
seeurity  parameters. 


4.2  Design  Goals 

Our  software  tool  should  reason  about  maehine-readable  proofs  and  attaek  metadata,  to 
provide  aeeurate  eonelusions  regarding  the  relationship  between  seeurity  parameters  and 
effeetive  seeurity.  In  addition,  our  software  tool  should  be  both  modular  and  extensible. 
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Modularity  allows  expertise  from  one  domain  (e.g.,  using  the  general  number  field  sieve  to 
perform  attacks  against  a  cryptosystem)  to  be  combined  with  that  of  another  domain  (e.g., 
the  state  of  attacks  against  a  particular  hash  function).  It  should  be  possible  to  develop 
modules  independently,  each  defining  their  own  symbols,  cost  parameters  and  relations.  A 
new  system  employing  both  number-theoretic  assumptions  and  hash  functions  may,  then, 
employ  these  modules  to  reason  about  complex  schemes.  It  should  be  possible  to  extend 
the  tool,  to  incorporate  new  reductions,  new  objectives  and  new  attacks.  An  extensible 
design  allows  organizations  to  incorporate  new  information  for  prompt,  informed  reactions 
to  newly  published  attacks. 

4.3  Software  Design 

We  identify  two  base  classes,  related  directly  to  our  use  of  attack  trees  for  reasoning  about 
data:  the  AttackEdge  and  AttackNode  classes.  Figure  4.1  is  a  detail  of  the  AttackEdge 
base  class  and  its  subclasses.  Figure  4.2  is  a  detail  of  the  AttackNode  base  class  and  its 
subclasses. 

4.3.1  Attack  Edges 

The  AttackEdge  class  represents  the  edge  in  a  directed  graph,  and  has  an  attribute  named 
parent  and  child  representing  the  nodes  it  connects.  Each  of  these  attributes  reference 
an  appropriate  AttackNode  class  instance  (see  Section  4.3.2).  Reduction  is  a  subclass  of 
AttackEdge,  representing  an  edge  annotated  with  a  reduction.  The  Reduction  subclass  has 
a  number  of  attributes:  full_name  is  intended  to  be  assigned  a  string  that  describes  the 
reduction;  expr  lists  the  expressions  describing  how  values  are  mapped  between  the  goal 
and  subgoal;  symbols _list  lists  the  symbols  used  in  the  reduction;  conservative _substitutions 
lists  a  set  of  conservative  substitutions  for  potential  free  variables  in  the  reduction. 
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Figure  4.1:  UML  diagram  for  the  AttackEdge  class. 


The  remaining  classes  in  Figure  4. 1  are  example  subclasses  of  the  Reduction  class  containing 
metadata  specific  to  our  case  study.  For  example,  PSOO  is  the  Pointcheval  and  Stern  reduction 
between  Break  EF-ACMA  and  Break  Subgroup  Discrete  Log  Problem.  DlPr  is  the  reduction 
between  Break  Discrete  Log  Problem  and  Pollard’s  Rho. 

4.3.2  Attack  Nodes 

The  AttackNode  base  class  has  the  full_name  and  symbolsjist  attributes,  and  they  serve  the 
same  role  as  in  the  AttackEdge  class.  Our  attack  tree  manages  two  types  of  nodes:  Objective 
nodes  and  Attack  nodes.  All  Attack  nodes  are  leaf  nodes,  i.e.,  do  not  have  children.  All 
Objective  nodes  represent  an  objective  or  subgoal,  such  as  “solving  the  discrete  log  problem.” 
An  Objective  node  may  have  one  or  more  children  (of  any  AttackNode  type)  and  one  or 
more  parents  (of  Objective  node  type). 
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Figure  4.2:  UML  diagram  for  the  AttackNode  class. 


The  Attack  class  has  the  attribute  expr,  a  list  containing  one  or  more  expressions  relating 
cost  parameters  and  security  parameters.  An  example  of  an  expression  contained  within 
the  expr  list  is  Tpr  =  ^fn  from  the  Pollard’s  Rho  node  in  Figure  3.7.  In  comparison,  the 
Objective  class  has  the  attribute  constraints,  a  list  of  zero  or  more  expressions  describing 
any  constraints  on  the  symbols  within  the  objective.  For  example,  in  our  Schnorr  case  study, 
the  Break  Subgroup  Discrete  Log  Problem  node  employs  the  constraint  q  <  p,  expressing 
that  the  order  of  the  subgroup  q  must  be  less  than  the  order  of  the  group  p. 
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CHAPTER  5: 

mplementation 


In  this  chapter  we  discuss  how  our  software  tool  and  its  routines  are  implemented.  In 
Sections  5. 1-5.4,  we  introduce  notation  and  describe  the  routines  for  our  analysis  engine.  In 
Section  5.5,  we  discuss  the  software  implementation  of  this  analysis  engine.  In  Section  5.6, 
we  provide  sample  analyses,  compared  with  existing  guidance. 


5.1  Notation 

The  pseudocode  expressing  the  algorithms  for  building  and  maintaining  our  data  structures 
employs  the  following  notation. 

Graph  Notation.  Each  graph  G  =  (N,  E)  is  a  directed,  acyclic  multigraph.  We  let  E{G) 
denote  the  edge  multiset  and  N{G)  denote  the  node  set. 

Nodes.  There  are  two  distinct  types  of  nodes.  Objective  nodes  and  Attack  nodes  (see 
Section  4.3.2).  We  let  0{G)  denote  the  set  of  Objective  nodes  and  J3l(G)  denote  the 
set  of  Attack  nodes,  where  N{G)  =  0{G)  (J  Jl(G)  and  0(G)  H  ~9l(G)  =  0 
Edges.  We  let  'R(G)  denote  the  set  of  reductions  associated  with  G.  Every  edge  is  annotated 
with  a  reduction,  so  \E(G)\  =  |!R(G)|.  Eor  e  e  E(G),  we  let  ji(e)  6  'R(G)  be  the 
reduction  associated  with  edge  e.  Alternative  notation  for  edge  e  =  (x,  y)  and  its 

r 

reduction  r  =  %(e)  include  x  ^  y,  x  ^  y  and  r(x,  y). 

Predecessor  and  Successor.  Given  edge  x  ^  y  e  E(G),  we  say  .r  is  an  immediate 
predecessor  (parent)  of  y,  and  y  is  an  immediate  successor  (child)  of  x.  Eor  edge  e  = 
(x,  y),  we  denote  .r  =  e. parent  and  y  =  e. child.  Similarly,  we  denote  .r  6  y. parents 
for  the  set  of  immediate  predecessors  and  y  6  .r. children  for  the  set  of  immediate 
successors.  More  generally,  we  say  n,  is  a  predecessor  of  nj  if  there  exists  a  series  of 
edges  Hi  tii+i,  rii+i  n,+2,  . . . ,  ny-i  ^  nj  connecting  n,-  to  nj.  By  definition,  if 
Hi  is  a  predecessor  of  nj,  then  Uj  is  a  successor  of  n/. 

Symbols.  Eor  v:  6  'R(G)  (J  0(G)  (J  Ji(G),  x  has  an  attribute  .r. symbols.  This  is  a  list  of 
symbols  associated  with  the  node  (see  Section  4.3.1  and  Section  4.3.2).  The  variant  at¬ 
tribute  .r.symbols^^^f  and  v:.symbolSp^^„„  selects  the  symbols  from  v:. symbols  that  are 
cost  or  security  parameter  symbols,  respectively.  Eor  different  nodes  n  A  m,  symbols 
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are  unambiguous,  i.e.,  m. symbols  H  n. symbols  =  0.  For  any  reduction  x  ^  y,  sym¬ 
bols  are  consistent  with  adjacent  nodes,  i.e.,  r. symbols  c  ;c. symbols  IJ  «/. symbols. 

Relations.  For  .r  6  *R(G)  U  0(G)  IJ  ^(G),  x  has  an  attribute  .^.relations.  This  is  a  list 
of  formulae  expressed  in  terms  of  constants,  relations  and  symbols  in  jc. symbols. 
When  X  6  0(G),  ^.relations  is  synonymous  with  the  x. constraints  attribute  (see  Sec¬ 
tion  4.3.2).  When  x  6  'R(G)  (J  J3l(G),  ^.relations  is  synonymous  with  x. expressions 
attribute  (see  Section  4.3.1  and  Section  4.3.2). 

Values.  For  x  6  0(G)  (J  Jl(G),  x  has  an  attribute  x. values.  This  is  a  list  of  values  associ¬ 
ated  with  X. symbols.  Initially,  this  list  has  no  values,  i.e.,  x. values  =  {(5,  -L)|  for  s  6 
X. symbols}.  When  a  value  for  symbol  5  is  derived,  then  (s,  v)  6  x. values  and  5  is  no 
longer  considered  a  free  symbol. 

Expressions.  Each  expression  x  has  a  number  of  attributes  and  support  functions.  The 
attribute  x.free_symbols  yields  the  set  of  free  symbols  in  expression  x.  The  function 
x.substitute(5,  s')  syntactically  replaces  the  symbol  s  with  symbol  s' .  The  function 
x.solve(5)  solves  expression  x  for  the  value  for  free  symbol  s. 

Assignment.  In  our  pseudocode,  x  <—  «/  is  the  assignment  operator  and  modifies  the 
original  object  x.  For  lists,  we  abuse  this  notation  to  denote  both  insertion  and 
update,  depending  on  context.  For  example  if  S  <—  0,  then  S  (x,y)  updates  the 
list  to  be  5  =  {(x,  y)}.  Subsequent  insertions  with  related  tuples,  e.g.,  S  <—  (x,  y') 
and  S  (x',  y"),  update  the  list  to  be  S  =  {(x,  y'),  (x',  y")}. 


5.2  Overview 

Our  software  tool  first  builds  the  Master  Graph  G  of  reductions  and  the  objectives  defined 
in  its  database.  Given  a  target  objective  ctq,  we  prepare  the  data  structure  used  for  analysis, 
called  the  Traceback  Graph,  using  the  following  steps: 

1.  Given  target  objective  ctq  e  0(G),  derive  the  subgraph  of  G  comprised  of  ctq  is  its 
successors  to  form  IV,  the  Working  Graph  (see  Figure  5.1). 

2.  Using  W,  initialize  T,  the  Traceback  Graph  (see  Figure  5.2). 

3.  Normalize  T  so  that  it  has  a  tree  structure,  by  duplicating  those  subtrees  with  multiple 
parents  (see  Figure  5.3). 
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1:  function  SuBGRAPH(graph  G,  target  ctq  g  0(G)) 

2:  graph  W  <—  (0, 0) 

3:  for  all  n  g  N(G)  where  (tq  g  ^.parents  do 

4;  add  n  to  N(W) 

5:  for  all  e  g  E(G)  where  e  =  (n,  n')  do 

6:  add  e  to  E(W) 

7:  end  for 

8;  end  for 

9;  return  W 

10:  end  function 

Figure  5.1:  Pseudocode  for  the  Subgraph  function. 

1:  function  iNixTRACEBACKfgraph  VF) 

2:  graph  T  <^W 

3:  forallx  6!R(r)U<5(r)do 

4:  A. values  0 

5:  for  all  5  e  a. symbols  do 

6:  X. values  <—  (s,  ±) 

7:  end  for 

8:  end  for 

9:  return  T 

10:  end  function 

Figure  5.2:  Pseudocode  for  the  InitTraceback  function. 

1:  function  NoRMALizETRACEBACKfgraph  T,  target  (Tq  6  0(G)) 

2:  for  n  G  N(T)  where  |n.parents|  >  1  and  depthfn,  cro)  is  max  over  N(T)  do 

3:  J  I «. parents  I 

4:  remove  n  from  N(T) 

5:  create  d  copies  of  n  and  its  successors  to  produce  subtrees  p\,...,pd 

6:  addpi, . .  to  r 

7:  modify  all  edges  (xi,  n)  G  E(T),  so  that  the  /-th  edge  is  (xi,pi) 

8:  r  NORMALIZE(r) 

9:  end  for 

10:  return  tree  T  with  root  ctq 

11:  end  function 

Figure  5.3:  Pseudocode  for  the  NormalizeTraceback  function. 


The  Traceback  Graph  is  used  to  hold  values  associated  with  the  symbols  for  objectives  and 
reductions  in  the  Working  Graph,  derived  as  we  traverse  up  or  down  the  attack  tree.  For  the 
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Master  Graph  and  Working  Graph,  it  is  possible  for  a  node  to  have  multiple  parents.  Thus, 
before  normalization,  traversing  down  the  Traceback  Graph  might  eause  nodes  to  be  visited 
twiee,  via  entirely  different  parents.  Sinee  derived  values  will  be  based  on  attributes  of  both 
parent  and  ehild,  it  would  be  ineorreet  to  diseard  or  update  a  value  based  on  information 
from  an  unrelated  parent.  Thus,  the  Traceback  Graph  is  normalized  to  form  a  tree,  ensuring 
eaeh  node  has  only  one  parent.  This  is  aeeomplished  by  duplieating  subtrees  that  would 
otherwise  be  re-visited.  After  normalization,  the  Traceback  Graph  has  the  same  number  of 
edges  as  the  Working  Graph  and  is  strueturally  identieal  to  traversing  the  Working  Graph  in 
depth-first  order.  As  an  added  benefit,  the  intermediate  values  generated  as  expressions  and 
eonstraints  are  proeessed  elosely  follows  walking  the  Working  Graph.  Thus,  the  Traceback 
Graph  allows  one  to  “traee  baek”  the  symbols  resolved  and  values  derived  at  eaeh  step  of 
walking  the  graph. 

At  this  point,  the  attaek  tree  is  prepared  for  analysis.  Analysis  solves  for  either  effeetive 
seeurity  (in  terms  of  cost)  or  settings  (in  terms  of  security  parameters)  needed  to  achieve 
a  particular  level  of  security  (see  Section  4.1).  For  example,  if  a  user  wants  to  solve  for 
the  cost  to  break  the  objective,  the  user  will  provide  the  security  parameters  for  the  scheme 
as  input.  Since  we  must  propagate  values  in  both  directions  within  our  attack  tree  (see 
Section  4.1),  analysis  is  a  two-pass  process.  PhaseOne  derives  values  from  the  root  to  the 
leaves,  and  PhaseTwo  from  the  leaves  to  the  root. 

1.  The  user  selects  target  symbols  related  to  objective  (Tq,  placing  these  in  the  global 
SOLVE  list. 

2.  The  user  builds  K,  a  set  of  known  values  for  other  parameters  related  to  ctq. 

3.  We  build  traverseList,  the  list  of  r  e  P.{T),  in  depth-first  order  starting  at  ctq. 

4.  PhaseOne:  we  utilize  Reductions  in  T  to  populate  values  down  the  tree,  where  we 
will  use  the  expressions  in  the  Attack  nodes  to  derive  the  values  needed  for  analysis 
and  save  these  in  T  (see  Figure  5.4). 

5.  PhaseTwo:  we  utilize  values  stored  in  T  during  the  first  pass  to  solve  for  remaining 
free  variables  (see  Figure  5.11). 

6.  If  successful,  a  value  {s,  v)  6  ctq. values  will  exist  for  any  symbol  5  e  SOLVE. 

In  the  following  sections,  we  elaborate  on  PhaseOne  and  PhaseTwo  and  the  routines  sup¬ 
porting  these. 
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5.3  First  Pass 

During  PhaseOne,  we  populate-down  values  from  the  root  the  leaves  (see  Figure  5.4).  We 
begin  by  moving  known  values  from  K  into  root  (Tq. 

1;  function  PHASEONE(tree  T  with  root  ctq,  known  values  K,  traverseList) 

2:  for  (s,  v)  e  K  where  5  6  o-q. symbols  and  (s,  J.)  6  (Tq. values  do 

3:  CTo. values  <—  (s,  v) 

4:  end  for 

5:  for  r(cri,  CTj)  e  traverseList  do 

6:  r  <—  PopuLATEKNOWNs(cr/,  r) 

7:  r  <—  REMOVEFREE(r. values,  r) 

8:  if  cTj  6  ^(T)  then 

9:  cry  RemoveFreeCp. values,  (Ty) 

10;  else  if  cry  6  0(T)  then 

11;  if  there  are  multiple  edges  for  (cr,,  a j)  then 

12;  CTj  <—  RESOLVEMuLTiEDGE(r. values,  cry,  cr,) 

13;  else 

14;  cry  <—  RESOLVE0BJECTIVE(r. values,  cry) 

15;  end  if 

16;  end  if 

17;  end  for 

18;  return  T 

19;  end  function 

Figure  5.4:  Pseudocode  for  PhaseOne. 


We  visit  each  edge  in  depth-first  order,  populating  known  values,  using  expressions  to  derive 
more  known  values,  simplifying  expressions  and  populating  values  to  adjacent  objectives. 
At  each  edge,  values  are  populated  from  parent  to  edge  (see  Figure  5.5),  changing  these 
according  to  their  symbol  type. 

Next,  known  values  at  edges  are  substituted  into  expressions,  following  the  same  process 
employed  at  attack  nodes,  i.e.,  leaves  (see  Figure  5.6).  If  there  are  enough  known  values 
to  eliminate  all  but  one  free  symbol,  we  will  have  effectively  determined  a  value  for  that 
symbol.  We  can  solve  for  the  free  variable  and  store  the  value. 
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1;  function  PopuLATEKNOwNs(node  cr,  r  e  ^{T)) 

2:  for  {s,v)  6  cr. values  and  5  6  cr. symbols  H  r. symbols  do 

3:  if  PhaseOne  then 

4:  r. values  {s,  v)  6  cr. values 

5:  else  if  (5,  v')  e  cr. values  and  5  6  cr.symbols^^^j  and  v  <  v'  then 

6:  r. values  {s,  v)  6  cr. values 

7:  else  if  is,v')  e  cr. values  and  5  e  cr.symbols^^^^^  and  v  >  v'  then 

8:  r. values  {s,  v)  6  cr. values 

9:  end  if 

10;  end  for 

11:  return  r 

12;  end  function 

Figure  5.5:  Pseudocode  for  the  PopulateKnowns  function. 


1;  function  REMOvEFREE(t)a/5,  p  6  'R(r)  IJ 
2:  for  expr  in  ju.relations  do 

3;  for  (5,  v)  6  vals  where  5  6  eAjur.free_symbols  do 

4:  expr  <—  eA;?r.substitute(5,  v) 

5:  end  for 

6:  if  5  G  cA;?r.free_symbols  and  |eApr.free_symbols|  ==  1  then 

7:  value  <—  ADVANTAGINGSuBSTITUTION(cAj!?r,  s) 

8;  if  PhaseOne  and  p  g  !R(r)  and  5  ^  SOLVE  then 

9;  p. values  <—  (5,  value) 

10;  else  if  (PhaseOne  and  p  g  or  PhaseTwo  then 

11:  ju. values  <—  {s,  value) 

12:  end  if 

13:  else  if  G  'R(r)  then 

14;  p  <—  CoNSERVATivESuBSTiTUTiON(eA;?r.free_symbols,  ju) 

15:  if  a  new  value  was  just  uncovered  by  the  previous  step  then 

16:  p  <—  REMOVEpREEfr,  Vals,  p) 

17:  end  if 

18:  else  if  P  G  Jl(T)  then 

19:  error  >  analysis  fails  if  attack  nodes  have  too  many  free  variables 

20:  end  if 

21:  end  for 

22:  return  p 

23:  end  function 

Figure  5.6:  Pseudocode  for  the  RemoveFree  function. 
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The  process  for  removing  a  free  variable  involves  deriving  values  for  symbols  based  on  re¬ 
lationships  in  reductions  (see  Figure  5.7)  and  employing  conservative  symbol  substitutions 
(see  Figure  5.8). 

1;  function  ADVANTAGiNGSuBSTiTUTiON(re/aizon,  symbol) 

2:  if  relation  is  “=”  then 

3:  exp  <—  relation 

4:  else  if  relation  is  either  “<”  or  “>”  then 

5:  exp  <—  GreaterSide(eAp)  =  (LesserSide(cAp)  -i- 1) 

6:  else  if  relation  is  either  “<”  or  “>”  then 

7:  exp  <—  GreaterSide(eAp)  =  LesserSide(cjcp) 

8:  end  if 

9:  value  exp.so\\e{s  ymbol) 

10;  return  value 

11;  end  function 

Figure  5.7:  Pseudocode  for  the  AdvantagingSubstitution  function. 


1;  function  CoNSERVATivESuBSTiTUTiON(/ree_5  r  6  ^(T)) 

2;  if  PhaseOne  then  >  during  PhaseOne 

3;  cr  r. child 

4;  else  >  during  PhaseTwo 

5;  cr  r. parent 

6;  end  if 

7;  if  cr. symbols  H  free_symbols  0  then 

8;  for  expr  6  r.conservative_substitutions  do 

9;  for  (s,v)  6  r. values  where  5  6  eApr.free_symbols  do 

10;  expr  <—  eApr.substitute(5,  v) 

11;  end  for 

12;  if  5  6  cApr.free_symbols  and  |eApr.free_symbols|  ==  1  then 

13;  value  <—  AoVANTAGINGSuBSTITUTIONfcApr,  s) 

14;  r. values  (s,  value) 

15;  end  if 

16;  end  for 

17;  end  if 

18;  return  r 

19;  end  function 

Figure  5.8:  Pseudocode  for  the  ConservativeSubstitution  function. 


Conservative  substitutions  are  “safe”  substitutions  based  on  bounds,  selecting  parameters 
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that  most  advantage  the  adversary.  This  is  often  required  when  reductions  employ  under¬ 
constrained  expressions  or  when  free  symbols  have  a  bound  but  no  known  parameter 
(discussed  in  Section  4.3.1).  Similar  rationale  is  employed  when  deriving  new  values  based 
on  relations,  re-arranging  equations  and  selecting  bounds  that  most  advantage  the  adversary. 

Next,  after  edge  expressions  are  simplified  and  new  values  have  been  derived,  we  populate 
down  values  to  child  nodes  (see  Figure  5.9).  The  values  stored  at  the  objective  node  are 
updated,  depending  on  the  type  of  symbol.  If  the  symbol  represents  a  cost  variable,  the 
edge  value  updates  the  value  if  it  is  smaller,  i.e.,  the  adversary  cost  is  smaller  using  the 
new  edge.  The  opposite  is  true  for  security  parameters,  i.e.,  the  new  edge  implies  a  larger 
parameter  is  required. 

1;  function  RESOLVE0BJECTivE(ya/5,  cr  e  0(T)) 

2:  for  {s,  v)  G  vals  where  5  g  cr. symbols  do 

3:  if  (5,  -L)  G  cr. values  then 

4;  cr. values  <—  (s,  v) 

5;  else  if  (5,  v')  g  cr. values  and  g  cr.symbols^^^f  v  <  v'  then 

6:  cr. values  <—  (5,  v) 

7:  else  if  is,v')  g  cr. values  and  g  cr.symbols^^^^^  and  v  >  v'  then 

8:  cr. values  <—  {s,  v) 

9:  end  if 

10:  end  for 

11:  returner 

12:  end  function 

Figure  5.9:  Pseudocode  for  the  ResolveObJective  function. 


For  the  case  when  multiple  edges  exist,  i.e.,  due  to  multiple  reductions,  populating  values 
down  to  the  child  node  requires  modification,  as  potential  values  populated  at  the  node 
must  be  withheld  until  all  reductions  are  processed  (see  Figure  5.10).  The  new  values  from 
each  edge  are  held  temporarily,  this  multi-edge  value  group  is  managed  analogously  to  how 
values  are  updated  at  the  child,  before  they  are  populated  to  the  child.  When  the  final  edge 
is  processed,  the  values  are  resolved  as  normal. 
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function  RESOLVEMuLTiEDGE(f;a/5,  cri,  0-2) 
if  this  is  the  first  (cri,  0-2)  edge  processed  then 

cri.mvals[cr2]  <—  0  >  holds  values  for  edges  between  cri  and  0-2 

cri.count[cr2]  total  number  of  edges  between  (cri,  cr2) 

end  if 

let  multv  =  cri  .mvals[cr2]  >  an  alias,  for  notational  convenience 

let  count  =  CTi  .count[cr2]  >  an  alias,  for  notational  convenience 

>  now,  process  one  edge,  i.e.,  associated  with  the  reduction  annotated  with  vals 
count  <—  count  -  1 

for  (5,  v)  6  vals  where  5  e  cri. symbols  do 

if  PhaseOne  then  >  during  PhaseOne 

if  (5,  -L)  6  multv  then 
multv  <—  (s,  v) 

else  if  (s,  v')  e  multv  and  5  6 
multv  <—  (5,  v) 

else  if  (5,  v')  6  multv  and  5  6 
multv  <—  (5,  v) 

end  if 
else 

if  (5,  -L)  6  multv  then 
multv  <—  (5,  v) 

else  if  (5,  v')  e  multv  and  5  e 
multv  <—  (5,  v) 

else  if  (5,  v')  e  multv  and  5  e 
multv  <—  (5,  v) 

end  if 
end  if 
end  for 

if  count  ==  0  then  >  this  was,  in  fact,  the  last  edge 

(Ti  RESOLVE0BJECTIVE(mM/ii;,  (Ti) 

end  if 
return  cri 
end  function 

Figure  5.10:  Pseudocode  for  the  ResolveMultiEdge  function. 


cri  .symbols^^^j  and  v  <  v'  then 
cri  .symbolSpa^a^  and  v  >  v'  then 

>  during  PhaseTwo 

cri  .symbols^^^j  and  v  >  v'  then 
cri  .symbolSp^^^^  and  v  <  v'  then 


5.4  Second  Pass 

After  our  first,  top-to-bottom  pass  where  values  are  populated  across  the  tree,  a  bottom-to- 
top  pass  is  performed  (see  Figure  5.11).  This  PhaseTwo  pass  is  similar  to  PhaseOne  and 
utilizes  the  same  support  routines.  To  traverse  back  up  the  attack  tree,  we  re-visit  edges  in 
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reverse  order. 


1;  function  PHASETwo(tree  T,  traverseList) 

2:  for  r(cr,-,  (Tj)  6  XQ\Qxsc{tr  averse  List)  do 

3:  if  (Tj  6  0{T)  then 

4:  r  PopuLATEKNOWNs(cry,  r) 

5;  end  if 

6:  r  REMOVEFREE(r. values,  r) 

7;  if  there  are  multiple  edges  for  (cr,,  cry)  then 

8;  (Ti  RESOLVEMuLTlEDGE(r. values,  Cr,',  (Tj) 

9;  else 

10;  (Ti  <—  RESOLVE0BJECTivE(r. values,  n/) 

11:  end  if 

12:  for  expr  6  r. relations  do 

13:  for  (s,  v)  6  r. values  where  6  e.x:pr.free_symbols  do 

14:  expr  <—  e.rpr.substitute(5,  v) 

15:  end  for 

16:  end  for 

17:  end  for 

18:  return  T 

19;  end  function 

Figure  5.11:  Pseudocode  for  PhaseTwo. 


Attack  nodes  should  now  be  fully  populated  with  values,  and  those  values  can  be  popu¬ 
lated  up  the  tree  from  child  to  parent.  Values  for  objectives  and  multi-edges  are  resolved 
analogously  to  prior  logic.  As  described  in  Section  3.2,  walking  up  the  tree  in  the  presence 
of  multiple  reductions  requires  slightly  different  logic:  assuming  all  reductions  are  sound, 
when  the  parent’s  cost  is  determined  to  be  greater,  we  consider  this  to  be  a  tighter  proof  and 
select  the  more  accurate  result  (with  analogous  reasoning  when  the  more  accurate  reduction 
allows  us  to  select  a  smaller  security  parameter). 

5.5  Python  Implementation 

We  implement  our  software  tool  in  the  Python  programming  language  version  3.5.1  [24] 
using  the  Anaconda  package  and  environment  manager  [25].  We  select  Python  because  it 
is  open  source,  widely  used  and  relatively  accessible,  all  of  which  support  the  extensibility 
goals  of  our  software  tool.  To  implement  our  attack  tree  data  structures,  we  employ  the 
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NetworkX  Python  module  version  1.11  [26] .  Of  interest  to  us,  NetworkX  supports  direeted, 
multi-graphs  and  provides  support  funetions  to  iterate  through  graph  components,  to  assign 
and  manage  data  associated  with  nodes  and  edges,  to  traverse  graphs  and  to  export  graphs 
to  formats  usable  by  graph  visualization  software.  To  manipulate  expressions  associated 
with  objectives,  attacks  and  reductions,  we  employ  the  Sympy  Python  module  [27].  This 
provides  support  for  expression  re-writing  and  symbolic  solving. 


5.6  Case  Study:  The  Schnorr  Signature  Scheme 


We  validate  our  software  tool  using  the  Schnorr  case  study  introduced  in  Section  3.3. 
Figure  5. 12  is  a  graphical  representation  of  the  tree — its  objectives,  reductions  and  attacks — 
comparable  to  Figure  3.7.  The  software  producing  this  visualization  does  not  draw  explicit 
multi-edges,  and  represents  edge  direction  using  line  thickness  rather  than  arrow  heads. 

EF-ACMA  of  the  Si  igital  Signature  Scheme 


Subgroup  Disc  Problem 


Shank's  Baby-;  iant-step  attack 


^huosiive  ^arch  Attack 


Figure  5.12:  Graph  for  the  Schnorr  case  study,  generated  by  our  software 
tool. 
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We  consider  two  analysis  cases  in  the  context  of  this  case  study,  both  employing  the  target 
objective  Break  EF-ACMA  for  cro,  the  root  of  our  analysis  tree. 

Case  1.  We  supply  our  software  tool  with  a  set  of  security  parameters  and  use  it  to  solve  for 
the  cost  to  break  the  Schnorr  scheme  in  the  EF-ACMA  sense.  This  requires  setting 
(i)  SOLVE  to  include  the  relevant  time  parameter  for  ctq  and  (ii)  known  values  that 
include  relevant  security  parameters  for  ctq.  We  are  essentially  asking  the  question 
“what  is  the  effective  security  for  EF-ACMA  with  the  Schnorr  signature  scheme  using 
the  chosen  security  parameters?” 

Case  2.  We  supply  our  software  tool  with  a  set  of  cost  parameters  and  use  it  to  solve  for 
security  parameters  for  the  Schnorr  scheme.  This  requires  setting  (i)  SOLVE  with 
relevant  security  parameters  and  (ii)  known  values  that  include  2^  as  the  target  time- 
cost  parameter.  We  are  essentially  asking  “under  what  parameters  will  the  Schnorr 
signature  scheme  achieve  an  effective  security  of  2^  for  EF-ACMA?” 

The  full  list  of  symbols  associated  with  attacks  and  objectives  in  the  subgraph  associated 
with  components  connected  to  ctq  is  given  in  Figure  5.13. 
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Symbols  for  node  Exhaustive  Search  Attack 


Es.n:  Key length 

Es.t:  Time 


Symbols  for  node  Shank's  Baby-step  Giant-step  attack 

BsGs.n:  Key length 

BsGs.t:  Time 


Symbols  for  node  Discrete  Log  Problem 

Dl.p:  Order  of  the  Group  in  Discrete  Log 

Dl.t:  Time  to  break  Discrete  Log 


Symbols  for  node  GNFS 


Gnfs.c: 

Gnfs.t: 

Gnfs.n: 


constant 

time 

n 


Symbols  for  node  EF-ACHA  of  the  Schnorr  Digital  Signature  Scheme 


Ef ACma . R 
Ef ACma . e 
EfACma.T 
Ef ACma . q 


Number  of  queries  to  the  signing  oracle 
Probablility  of  success  of  the  attack 
Time  to  break  Schnorr  Signature  under  EF-ACMA 
Number  of  queries  to  the  random  oracle 


Symbols  for  node  MGNFS 

HGnfs.n:  n 

MGnfs.t:  time 


Symbols  for  node  Pollard's  Rho  Attack 

Pr.t:  Time 

Pr.n:  Key length 

Symbols  for  node  Subgroup  Discrete  Log  Problem 

Sdl.t:  Time  to  break  Subgroup  Discrete  Log 

Sdl.p:  Order  of  group  in  Subgroup  Discrete  Log 

Sdl.q;  Order  of  subgroup  in  Subgroup  Discrete  Log 

Figure  5.13:  Attack  and  objective  symbols  for  the  Schnorr  case  study. 


For  Case  1,  a  sample  run  of  our  software  tool  is  provided  in  Figures  5.14  and  5.15,  showing 
values  assoeiated  with  eaeh  node  and  edge.  In  this  ease,  the  level  of  effeetive  seeurity  is 
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determined  to  be  «  2^^-^  when  using  the  following  security  parameters:  the  order  of  the 
group  is  the  order  of  the  subgroup  is  2^^®,  the  probability  of  success  to  1 .0,  the  number 

of  queries  to  the  both  Break  EF-ACMA  random  oracles  as  2^^'^,  the  number  of  queries  to 
the  random  oracle  within  the  Schnorr  reduction  to  2^^.  In  reality,  the  random  oracle 
parameters  are  inferable  based  on  running  time  bounds;  however,  we  defer  to  future  work 
enhancements  to  employ  conservative  symbolic  substitution — i.e.,  symbolic  re-writing  of 
expressions  based  on  conservative  relations — rather  than  our  more  simple  approach  of 
conservative  value  substitution. 


The  values  for  node  EF-ACMA  of  the  Schnorr  Digital  Signature  Scheme  are  as  follows: 

EfACma.R  2''31 . 50e00ee000000 
Ef ACma . e  1 

EfACma.T  2''31. 6191011974573 
EfACma.q  2''31 . 5000000000000 


The  values  for  node  Subgroup  Discrete  Log  Problem  are  as  follows: 

Sdl.t  2''80 

Sdl.p  2''1024 

Sdl.q  2''160 


The  values  for  node  Discrete  Log  Problem  are  as  follows: 

Dl.p  2''1024 

Dl.t  2''86. 7661192502810 


The  values  for  node  MGNFS  are  as  follows: 


HGnf  s .  n  2''1024 

HGnfs.t  2''86. 7661192502810 


Figure  5.14:  Case 


1  output,  showing  node  data  when  solving  for  cost. 
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The 

values 

for  edge 

EF-ACHA  <=>  Subgroup  Discrete  Log  i 

Ef ACma . R 

2''31 . 50G0eG0eG0eG0 

Ef ACma . T 

2''31. 6191011974573 

Sdl.q 

2''160 

Sdl.t 

2''80 

EfACma.e 

1 

Ef ACma . q 

2^31.5000000000000 

The 

values 

for  edge 

EF-ACMA  <=>  Subgroup  Discrete  Log  i 

Sdl.t 

2''80 

Ef ACma . e 

1 

EfACma.T 

2''20 

Ef ACma . q 

2A19 

The 

values 

for  edge 

Subgroup  Discrete  Log  <=>  Discrete 

Sdl.t 

2''86. 7661192502810 

Sdl.p 

2''1024 

Dl.p 

2''1024 

Dl.t 

2''86. 7661192502810 

The 

values 

for  edge 

Discrete  Log  <=>  Exhaustive  Search 

Es.n 

2''1024 

6s. t 

2''1023 

Dl.p 

2''1024 

Dl.t 

2''1023 

The 

values 

for  edge 

Discrete  Log  <=>  Pollard’s  Rho  are 

Pr.t 

2''512 

Dl.p 

2''1024 

Pr.n 

2''1024 

Dl.t 

2A512 

The 

values 

for  edge 

Dl  <=>  Meta  GNFS  are  as  follows: 

Dl.p 

2''1024 

MGnfs.n 

2''1024 

MGnfs.t 

2''86. 7661192502810 

Dl.t 

2''86. 7661192502810 

The 

values 

for  edge 

M  <=>  Q  are  as  follows: 

Gnfs . c 

1.92299942707654 

Gnfs.t 

2'^86. 7661192502810 

MGnfs . n 

2''1024 

MGnfs.t 

2''86. 7661192502810 

Gnfs . n 

2''1024 

The 

values 

for  edge 

Discrete  Log  <=>  Shank’s  Baby-step 

BsGs.n 

2''1024 

Dl.p 

2''1024 

BsGs.t 

2''512 

Dl.t 

2''512 

The 

values 

for  edge 

Subgroup  Discrete  Log  <=>  Pollard': 

Sdl.t 

2''80 

Pr.t 

2''80 

Sdl.q 

2''160 

Pr.n 

2''160 

s  Rho  are  as  follows: 


Figure  5.15:  Case  1  output,  showing  edge  data  when  solving  for  cost. 


For  Case  2,  a  sample  run  of  our  software  tool  is  provided  in  Figures  5.16  and  5.17,  showing 
values  assoeiated  with  eaeh  node  and  edge.  Providing  2^^-^  as  the  time  bound  for  node 
Break  EF-ACMA  eorresponds  to  deelaring  that  the  best-known  attaeks  breaking  EF-ACMA 
must  take  a  time  exeeeding  2^^  -^,  whieh  provides  31.5  bits  of  effeetive  seeurity.  The  analysis 
yields  that,  to  ensure  this  level  of  seeurity,  one  must  ehoose  the  order  of  the  subgroup  to  be 
at  least «  2^^*^. 
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The  values  for  node  EF-ACMA  of  the  Schnorr  Digital  Signature  Scheme  are  as  follows: 

EfACma.R  2 ''3 1.5000000000000 

EfACma.e  1.00000000000000 
EfACma.q  2 ''3 1.5000000000000 

EfACma.T  2 ''3 1.5 000000000000 


The  values  for  node  Subgroup  Discrete  Log  Problem  are  as  follows: 

Sdl.q  2''159. 761797605085 
Sdl.p  2''159. 761797605085 
Sdl.t  2''79. 8808988025427 


The  values  for  node  Discrete  Log  Problem  are  as  follows: 


Dl.p  2''159. 761797605085 

Dl.t  2''79. 8808988025427 


Figure  5.16: 
parameters. 


Case  2  output,  showing  node  data  when  solving  for  security 
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The  values  for  edge  EF-ACMA  <->  Subgroup  Discrete  Log  (Pointcheval  and  Stern)  are  as  follows: 


EfACma.R 

EfACma.e  1 . DeoDDeeeoDeDee 

EfACma.q  2^31.50e&0eDe&0000 

EfACma.T  2''31.50000eD0&00d0 

Sdl.q  2'^159. 761797605085 

Sdl.t  2^79.8808988025427 


The  values  for  edge  EF-ACMA  <=>  Subgroup  Discrete  Log  (Schnorr)  are  as  follows: 

EfACma.e  1.00000000000000 
Sdl.t  2''79. 8808988025427 

EfACma.q  2^31 . 5000000000000 

EfACma.T  2^31 . 5000000000000 


The  values  for  edge  Subgroup  Discrete  Log  <=>  Discrete  Log  are  as  follows: 


Sdl.p 

2^159.761797605085 

Dl.p 

2''159. 761797605085 

Sdl.t 

2'^79. 8808988025427 

Dl.t 

2^^79.8808988025427 

The  values  for  edge  Discrete  Log  <=>  Exhaustive  Search  are  as  follows: 


Es.n 

2^80.8808988025427 

Dl.p 

2''80. 8808988025427 

Es.t 

2''79. 8808988025427 

Dl.t 

2''79. 8808988025427 

The  values  for  edge  Discrete  Log  <*>  Pollard's  Rho  are  as  follows: 


Pr.n 

2^159.761797605085 

Dl.p 

2^^159. 761797605085 

Dl.t 

2''79. 8808988025427 

Pr.t 

2^79.8808988025427 

The  values  for  edge  Discrete  Log  <=>  Shank's  Baby-step  Giant-step  are  as  follows: 


BsGs.t  2''79. 8808988025427 
Dl.p  2''159. 761797605085 
D1 .  t  2''79 . 8808988025427 
BsGs.n  2''159. 761797605085 


The  values  for  edge  Subgroup  Discrete  Log  <~>  Pollard's  Rho  are  as  follows: 


Pr.n 

2''159. 761797605085 

Sdl.q 

2''159. 761797605085 

Sdl.t 

2^79.8808988025427 

Pr.t 

2'^79. 8808988025427 

Figure  5.17:  Case  2  output,  showing  edge  data  when  solving  for 
parameters. 


secu 
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While  testing  our  software  tool,  we  diseovered  it  was  eapable  of  solving  for  time  within 
the  GNFS  attack,  however  solving  for  parameters  proved  more  complex.  We  suspect 
the  problem  involved  limits  associated  with  the  symbolic  solver:  SymPy  appears  to  lack 
solvers  able  to  handle  computing  n,  given  T  and  c,  in  the  super-polynomial  sub-exponential 
relationship  for  attacks  employing  the  general  number  field  sieve: 

T  =  exp(clnn^''^  Inlnn^^^). 

As  a  result,  the  node  for  the  GNFS  attack  and  the  edge  connecting  it  to  the  rest  of  the  tree 
are  missing  from  Figures  5.16  and  5.17.  We  leave  for  future  work  further  verification  of 
this  problem  and  investigation  into  solutions  or  alternatives  for  this  scenario. 

Comparing  the  results  of  our  analyses  to  existing  guidance.  Figure  5.18  displays  a  selection 
of  the  key-length  guidance  for  schemes  based  on  the  security  of  the  discrete  log  problem, 
equating  these  to  the  cost  of  security  for  a  symmetric  scheme  (i.e.,  characterizing  its 
effective  security).  The  Schnorr  signature  scheme  employs  discrete  log  assumptions.  The 
“key”  and  “group”  parameters  from  Figure  5.18  can  be  equated  to  the  symbols  Sdl.q  and 
Sdl.p,  respectively,  in  our  case  study  (see  Figure  5.13). 


Figure  5.18:  Parameters  for  discrete  log  schemes,  for  key  size  160  and 
a  discrete  log  group  size  1024.  Source  [3]:  D.  Giry.  (2015).  BlueKrypt- 
cryptographic  key  length  recommendation.  [Online].  Available:  http://www. 
keylength.com. 


40 


Given  a  160-bit  subgroup  and  1024-bit  group,  our  software  tool  returns  an  effeetive  seeurity 
of  80  bits  for  the  Break  Subgroup  Discrete  Log  Problem  seeurity  objeetive  (see  Figure  5. 14), 
matehing  the  effective  security  for  many  recommendations  from  Figure  5.18.  Given  224-bit 
subgroup  and  2048-but  group,  our  software  tool  returns  an  effective  security  of  112  bits; 
interestingly,  this  is  less  than  that  claimed  by  the  BSI  recommendation  from  Figure  5.18. 
Using  a  128-bit  target  effective  security.  Figure  5.19  summarizes  the  discrete  log  parameters 
from  existing  guidance  and  Figure  5.20  shows  our  results. 


Figure  5.19:  Parameters  for  discrete  log  schemes,  comparable  in  strength 
to  128-bit  symmetric  encryption.  Source  [3]:  D.  Giry.  (2015).  BlueKrypt- 
cryptographic  key  length  recommendation.  [Online].  Available:  http://www. 
keylength.com. 


The  values  for  node  Subgroup  Discrete  Log  Problem  are  as  follows: 

Sdl.t  2''128 
Sdl.q  2''256 
Sdl.p  2''256 


The  values  for  node  Discrete  Log  Problem  are  as  follows: 

Dl.t  2''128 

Dl.p  2''256 

Figure  5.20:  Results  from  our  software  tool  using  128-bit  effective  security. 
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CHAPTER  6: 
Conclusion 


We  have  described  the  current  complexity  and  methodology  to  reason  about  cryptographic 
schemes,  using  reductionist  proofs  and  data  about  known  attacks  for  the  practice-oriented 
goal  of  parameter  selection.  State-of-the-art  is  to  employ  generic,  conservative  recommen¬ 
dations  published  periodically,  which  are  not  necessarily  current  or  informed  by  recently 
disclosed  attacks.  We  developed  a  proof-of-concept  software  tool  capable  of  reasoning 
about  keylength  for  cryptographic  schemes  using  machine-readable  proof  metadata.  In 
support  of  this,  we  formalized  reasoning  about  cryptographic  adversaries  within  the  attack 
tree  model,  and  expanded  attack  trees  to  include  proof  reductions. 

For  this  tool,  we  described  a  concept  of  operations,  use  cases  and  design  goals.  We  argued 
the  software  tool  should  be  able  to  provide  recommendations  about  keylength  when  given 
a  set  of  parameters,  as  well  as  provide  parameters  necessary  to  achieve  a  target  effective 
security.  From  there  we  presented  the  software  design  to  achieve  the  stated  goals  and 
provided  the  algorithms  to  implement  the  software.  We  validate  our  software  tool  utilizing 
the  Schnorr  public-key  signature  scheme  as  a  non-trivial  case  study. 

While  our  prototype  had  some  limitations  unrelated  to  our  methodology,  overall  we  showed 
that  automating  reasoning  about  keylength  and  effective  security  is  achievable.  When 
the  attack  and  proof  metadata  is  provided  in  a  machine-readable  format,  our  software 
tool  achieved  the  desired  goals  of  providing  accurate  and  timely  information  specific  to  a 
particular  scheme.  Additionally,  modularity  and  extensibility  were  achieved  by  designing 
the  software  tool  in  a  way  that  allows  experts  to  contribute  knowledge  from  their  domain, 
connecting  it  to  a  graph  of  other  proof  knowledge  and  facilitating  its  use  in  an  automated 
framework. 


6.1  Future  Work 

Further  investigation  into  the  limitations  of  our  implementation,  as  presented  in  Section  5.6, 
is  warranted.  It  will  be  necessary  to  verify  that  the  limitations  stem  from  the  solver’s 
inability  to  handle  particular  situations,  rather  than  a  mistake  in  the  implementation  of 
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our  software  tool.  Then,  onee  the  problem  is  properly  framed,  the  implementation  ean 
be  refitted.  We  also  believe  it  is  fruitful  to  expand  the  library  of  attaeks  and  objeetives 
to  inelude  other  ease  studies  employing  eonerete  seeurity  reduetions.  Lastly,  work  ean  be 
done  to  bridge  automatie  proof  generation  as  explored  in  prior  work,  and  automatie  proof 
analysis  as  explored  here. 
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